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Abstract 

We have developed an integrated software module for use in free 
space Optical communication using Polarization Shift Keying. The 
module provides options to read the data to be transmitted from a 
file, convert this data to on/off code for laser diodes as well as measure 
the state of polarization of the received optical pulses. The Software 
bundle consists of separate transmitter and receiver components. The 
entire protocol involves handshaking commands, data transmission 
as well as an error correction based on post-processing Hamming 7,4 
code. The module is developed using Lab VIEW, a proprietary soft¬ 
ware development IDE from National Instruments Inc. USA 

keywords: Polarization Shift Keying, Lab VIEW, Hand¬ 
shaking, Hamming code. 
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1 Introduction 

PolSK involves encoding the message bits with polarization state of 
a light pulse during transmission. The bits 0 and 1 are respectively 
mapped to two orthogonal states of polarisation. PolSK has several 
advantages since light can be decomposed into several sets of mutu¬ 
ally orthogonal polarisations, such as Vertical/Horizontal, 45°/135° or 
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RCP/LCP combinations. In each of this case, the two encodings are 
mutually orthogonal, in the sense that a light polarised in one state 
will show zero for measurement for other polarization. This results 
in an unambiguous measurement, except in presence of noise. This 
also becomes particularly useful in multibit-per-symbol transmission 
[5], although the different basis are not mutually exclusive and hence 
can provide ambiguity. 

We have developed an integrated software module to control and 
automate the above protocol using Lab VIEW. The program involves 
all relevant modules necessary to be used in PolSK communication. 
Although it is developed with our particular laboratory setup in mind, 
it is independent of the hardware involved and can be adopted with 
any other similar or compatible hardware. 


2 The Lab VIEW Program 

Labview is a graphical programming interface developed and distributed 
by National Instruments Inc. USA HE]. This has two distinct advan¬ 
tages over other programing environments - (i) the graphical method 
of programming makes it easier by removing the need to remember 
the code words, (ii) it has built-in modules to interface many differ¬ 
ent types of hardware units and (iii) can create an executable binary 
version, which can run on a different computer without installing Lab- 
view, although this facility is available only on the professional ver¬ 
sions. The ease of use and availability of extensive built-in modules 
has made Lab VIEW very popular in case of laboratory automation 
as well as controlling communication protocol mm®. While many 
of the earlier work uses Lab VIEW options to control TCP/IP and 
built-in communication protocols, we use a control program through 
DAQ card, which makes the system independent of hardware, i.e., the 
hardware consisting of diode lasers or APD’s can easily be replaced 
without any modification of the software. 

We have two independent parts of the code - the transmitter and 
the receiver part, each running on two independent computers. The 
synchronization between these two codes is explicitly obtained by the 
Labview code and hence does not demand identical clock speeds or 
memory for these two computers. In other words, the labview code is 
independent of the hardware parameters of either of the computers. 

The code described here is particularly designed for use in our ex- 
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perimental setup, although it can easily be used for any other schemes 
as it is, or at best with very little modification. Our setup is described 
in detail in an earlier communication [6] and will be very briefly re¬ 
counted here for sake of completeness. 

The Transmitter 

The transmitter consists of two VCSEL lasers, operating at 780 nm 
placed about a Polarizing beam splitter (PBS) as shown in figure [l] 
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Figure 1: Schematic of the communication setup. Laser 1 and 2 are VCSEL 
lasers. PBS are polarizing beamsplitters. APD are Avalanche Photo Diode 
Modules 


The lasers and the PBS are arranged in such a way that vertically 
polarized part of light from laser 1 and horizontally polarised part of 
light from laser 2 are coupled into the communication channel. The 
lasers are controlled by the computer through a DAQ card, which in 
turn fires the laser controller. Laser 1 would be switched on if the 
message bit is 0 and Laser 2 would be switched on if the message bit 
is 1. This would require the Labview code to encode as 


bit 

encoding 

0 

01 

1 

10 


The Labview code achieves this by operating a transformation 
k 2 k Binary y encoded number 

where k is the message bit and the encoded number be as per table 
above. In addition, a clock pulse, either another VCSEL in case of an 
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all-optical networking, or a pulse transmitted over a wire in case of a 
hybrid connection could be used. We have tried both and the same 
software accounts for either of the method. With the clock pulse, the 
encoding scheme becomes 


bit 

encoding & clock 

0 

Oil 

1 

101 

no bit 

000 


The need for this clock pulse is explained the receiver section. 
Figure ([ 2 ]) shows the initial module of the transmitter which generates 
a random sequence of 0’s and l’s, converts it into a relevant format 
and writes it onto the digital port of the DAQ card using the DAQmx 
module of Lab VIEW. This module was later replaced by the one which 
reads actual data from a saved file on the disk and similarly sends it 
to the DAQ card’s output, which is shown in section [3] 



Figure 2: initial module of the transmitter. Generates a random sequence of 
0’s and l’s, converts it into a relevant format and writes it onto the digital 
port of the DAQ card using the DAQmx module of Lab VIEW. 


Receiver 

The receiver consists of another PBS whose output is incident on two 
Avalanche Photo Diodes APD1 and APD2. The APD’s used in our 
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setup was PCD-mini 200 from SenSL. Any other SPC module which 
operates in Gieger mode and provides TTL pulses for each incident 
photon would work equally good. The TTL pulses from the APD 
module are connected to counter pints of the DAQ card NI - PCI - 
6320. This card has 4 counter inputs, each with 32 bit resolution and 
a rate of 25 MHz with external clock. The receiver part of the Labview 
code is designed to obtain these TTL pulses during the on-time of the 
clock pulse and total them. The code resets the total number each 
time the clock pulse is off. This aspect required a certain round about 
method within the code since the original counter-handling aspect 
built into the Labview does not contain the reset feature, which is 
otherwise very important for our protocol. 


Operation of the protocol 


The generic aspects of the protocol is graphically represented in figure 
(3(a)). As per this, the steps involved are (i) Alice opens up the 
protocol with a wake up call (ii) Bob acknowledges (iii) Alice asks 
Bob to identify himself - so as to ensure that the data is given only to 
authorized receiver, (iii) Bob answers with a pre-agreed ID number, 
(iv) Alice compares this with the one stored in her computer and if 
it matches the protocol proceeds. She acknowledges it (v) Then Alice 
starts a Data Start code and proceeds to transmit all the data, (vi) 
Bob stores the data on his computer (vii) Alice concludes transmission 
with an EoD code, (viii) Bob acknowledges receipt of all data (vi) 
Alice concludes the protocol with End-of-Protocol code. 

The corresponding flow chart for the transmitter and receiver are 
given in figure |3(b)[ They represent the steps (i) through (viii) de¬ 
scribed above. Two individual LabView codes are 

The protocol makes use of a set of standard commands which 
are used by both Alice and Bob, such as codes for Acknowledgment 
(ACK), Start of Data etc. Since these codes are a one-time standard, 
shared both by Alice and Bob, and any other parties involved, a we 
create a set of global variables for this purpose. The entire set can be 
shared as it is by all parties. The set of codes are shown in figure Q 

These codes are same for both Alice and Bob, and they pick ap¬ 
propriate global variable from the Global VI. A typical set of global 
codes would look like 

Handshake protocols are shown in figures fig |5(a) and |5(b)} These 
two modules are for transmission and receiving Figure [5(a) shows 
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End of data 

End protocol 
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Figure 3: (a) Elements of the protocol and (b) Corresponding flowchart of 
decision making 


This is Communication, 

.Global 

All required command sequence are stored here and used as required by 
both Transmitter and Reciever 

(When new protocol is added, always remember to "Make current value default" in Bata 
operations 

Start of Protocol 

gp")*ooooo»« 

Alice wakes up Bob. Expects ACKI 

(•QOQOO®® 

Alice asks Bob to Identify. Bob replies with pre-approved string 

ACK 

Alice tells Bob when data starts. No reply reqiired 

;• 

Both Alice & bob use this a3 Acknowledge 

j%T 

Alice Tells Bob size of data. Expects ACK 

data end 

(•GOO • • • • 

Alice tells Bob end of Data. Expects ACK 


Figure 4: Front panel of the Global VI, showing all the codes for handshaking 


the Lab VIEW module for the handshake protocol. These modules 
exchange appropriate words from the Global VI between transmitter 
and receiver. 
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Mnemonic Binary code Description 


Protocol Start 

0011 1110 

Alice wakes up Bob 

Identify 

0010 1110 

Alice asks Bob to identiy - 
Bob answers a 
pre-approved Identity code 

Data start 

0001 1100 

Alice tells Bob when 
data starts. 

Bob starts recording data 

ACK 

0101 0100 

Acknowledge 

Data size n 

1101 0100 

n is size of data in kbits 

Data end 

0000 1110 

End of Data (by Alice) 

Protocol End 

mi mi 

Final closing of protocol 

Table 1: 

Typical set 

of codes for the global handshaking 




(a) LabView module to transmit 
the global VI codes 


(b) LabView module to receive the global VI 
codes from Bob and compare with the stored 
bob’s IDN 


3 Transmitter module 

The Lab VIEW module for transmitter is shown in [5j This program 
reads a binary file from the hard disk and convert it into individual 
bits for transmission through serial transmission. These bits are then 
converted into 8 bit word and then sent to write-to-port module of 
DAQ card. 
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Figure 5: Lab view Code to read a binary file, in this case an image and 
extract individual bits for serial transmission 



Figure 6: The complete receiver module 

3.1 Receiver 

The Lab VIEW component for the receiver runs on an independent 
computer, recording data from the two APD modules as shown in 
schematic [lj The program is started independently of the transmit¬ 
ter program and therefore at the beginning has a waiting loop with 
continuously analysing signals received at the input. If the signal 
corresponds to previously agreed handshaking commands from Alice, 
only then the program goes to the next step. The all optical version 
of the module receives and analyses signal. The complete module is 
shown in figure [6| It contains four subunits, which are described below 
and shown separately in following figures for sake of clarity. 

The first module is shown in figure [lOj The two counters are ini¬ 
tialized (top and bottom of the figure) as well as the received signal is 
compared for ’Identify’ code. The identification of Bob is the merely 
ensure that Alice is transmitting the message to only authorized re¬ 
ceiver and not to any one else. 

As mentioned in previous section, the module is built around NI 
DAQ card PCI 6320 but in reality uses Lab VIEW modules which are 
hardware independent and hence can be used with any other card with 
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Figure 7: First module of the Receiver. It initialises relevant parameters of 
DAQ and also waits in a ‘while’ loop until it receives an ’Identify’ command 
from receiver. 

similar features. The APD modules provides TTL signals for every 
photon that is incident on them, which are fed to the counter inputs 
of the DAQ card. The Lab VIEW module follows the steps (i) Create 
a Counter Input channel to Count Events. The Edge parameter is 
used to determine if the counter will increment on rising or falling 
edges. (ii)Call the DAQmx Timing VI (Sample Clock) to configure 
the external sample clock timing parameters such as Sample Mode, 
Samples per Channel, and Sample Clock Source. The Edge parameter 
can be used to determine when a sample is taken, (iii) Call the Start VI 
to arm the counter and begin counting. The counter will be preloaded 
with the Initial Count, (iv) For finite measurements, the counter will 
stop reading data when the Samples per Channel have been received. 

(v) Call the Clear Task VI to clear the Task, (vi) Use the pop-up 
dialog box to display an error if any. 

The program takes input from two APD’s on two counter channels, 
totals the TTL signals obtained within till the edge detector detects 
fall of the clock pulses. Since the modules are not equipped with 
intermittent resetting of the counter, the counts within a clock pulse 
duration is obtained by subtracting old total from new total. The 
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software also computes ’State of Polarization’ as given by [6] 

5 = (APD! - APD 2 )/(APD 1 + APD 2 ) (1) 

APDi ? 2 indicates counts on respective APD’s within the clock pulse 
duration. If the value of S is positive, the program assigns data to 
1 and if S is negative, the data is assigned to 0. As explained in 
reference j6], this differential method of measurement provides a higher 
threshold against depolarization noise due to atmospheric effects. 



Figure 8: Second module of the Receiver. The module sends an acknowledge 
signal to Alice and proceeds further. 

The second module takes care of handshaking, in particular that of 
sending ACK signals to Alice. The third module is the main subunit 
which computes SoP as per equation [l] and also saves the data onto a 
file for further processing. 


4 Error Correction using Hamming codes 

Hamming code [7J is one of the industry standard algorithms to detect 
and correct bit flip errors during transmission. The most practical 
configuration is the (7,4) mode, wherein three parity bits {pi,p 2 and 
Ps) are added to four data bits (c^, i — 1,2, 3,4), adding upto 7 bits. 


Pi = di © d 2 © d 4 

p 2 = d\ © G?3 © d 4 

P3 = d 2 © d 3 © d 4 (2) 

While in normal circumstances the parity bits are computed and 
interspersed with the data so as to make a 7 bit word as pi,p 2) di,p 3 , 
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Figure 9: This is the main unit of receiver, which takes the counts from two 
counters and computes State of Polarization (labled as Degree of Polarization 
- DoP on module) and also saves this data on a file on disk. 



Figure 10: Final module of the Receiver. Saves all the data and sends an 
ACK to Alice 

d 2 ,d 3 ,d 4 . However, since we started working with random numbers 
initially, we adopted a method wherein the data are sent at first and 
the parity bits are computed and transmitted later. This method was 
particularly adopted for use in a future use of Quantum Key Distribu¬ 
tion protocol [8] wherein the data bits would be sent through quantum 
channel while the parity through the classical channel. However, the 
mathematics related to the computation and use of the syndrome set 
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was identical whether the parity bits were transmitted interspersed 
with data bits or otherwise. 

The Lab VIEW code for this part consists of the transmitter part 
computing the relevant parity bits and create the Generator matrix 
G. The receiver code has modules to use this matrix G, identify the 
error as per standard methods and then correct them. 



Figure 11: Receiver module of the Hamming correction code to read the 
generator matrix G and operate it on the data 

This protocol is valid to correct any single bit flips within each set 
of four data bits. 


5 conclusion 

We have prepared an integrated Lab VIEW program for use of free 
space optical communication system using Polarization Shift Keying 
with Binary coding. The program is designed to control two diode 
lasers, each providing light polarized in orthogonal directions, ini¬ 
tially mapped to bits 0 and 1. Corresponding light polarization is 
measured at the receiver, with the help of a Polarizing Beam Splitter 
(PBS) and a pair of Avalanche Photo diodes (APD). This measure¬ 
ment is in form of a ‘State of Polarization’, which takes into account 
any polarization scrambling during traverse through atmosphere. The 
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differential method adopted provides a higher threshold against noise. 
The LabVIEW program presented here integrates all these aspects 
as well as all the relevant handshaking commands. It also includes a 
(7,4) Hamming code error correction protocol, but with a post process 
option. 

Two main advantages of LabVIEW is that of having a graphical 
programming interface as well as several required modules already 
built-in. In this program, we exploit the digital output of a DAQ 
card to pulse the lasers appropriately for transmitter side and time 
synchronised counter acquisition to count the pulses from an SPCD 
module on the receiver side. The protocol is completely integrated 
and contains handshaking protocols as well as the Hamming code for 
error correction. At the same time, it is also modular so that individual 
components can be corrected or replaced as required. Full professional 
versions of LabVIEW also allow creating a stand-alone executable 
module, which can be run on independent computers. Future goal is 
to convert the present protocol for embedded versions such as FPGA 
or Raspberry Pi. 
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